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CROSS-REFERENCE TO RELATED U.S. PATENT APPLICATION 

The present application is related in subject matter to and cross - 
referenced with U.S. Patent Application Serial. No. 09/(Attorney's Docket No. 

10 D/A0613Q) (entitled "JOB SUBMISSION SYSTEM AND METHOD FOR 
CONTROLLING MULTIPLE JOB RENDERINGS WITH A SINGLE MASTER 
OR 'SUPER" TICKET'"), the cross-reference application being filed by 
Robinson et al. on the same day as the present Application. The disclosure of 
the above-mentioned application is incorporated herein by reference. 

15 FIELD OF THE INVENTION 

The present invention relates to a job control system (or method 
therefor) in which multiple job "tickets" created for a single document are 
selectively activated with, for instance, a master or "super" ticket to produce 
various physical forms or renderings of the document in a single submission 

20 session. 

BACKGROUND OF THE INVENTION 
Electronic printing systems include an input section, sometimes 
referred to as an input image terminal ("IIT"), a controller, sometimes referred 
to as an electronic subsystem ("ESS") and an output section or print engine, 
25 sometimes referred to as an image output terminal ("IOT"). In one type of 
electronic printing system, manufactured by Xerox known as the DocuTech 
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electronic publishing system ("DocuTech" is a registered trademark of Xerox 
Corporation), a job can be inputted to the NT from, among other sources, a 
network or a scanner. An example of an I IT with both network and scanner 
inputs is found in U.S. Patent No. 5,170,340 to Prokop et al. (Issued: 

5 December 8, 1992). 

When a scanner is employed to generate the job (in the context 
of, for example, a digital copier), image-bearing documents are scanned so 
that the images therein are converted to image data for use in making prints. 
When a network is used to generate the job, a stream of data, including 

10 various job related instructions and image data, expressed in terms of a page 
description language is captured, decomposed and stored for printing. As is 
known, a network job can have its origin in a remote client, such as a 
workstation, or a print server with a storage device. 

Electronic printing systems, sometimes also called "electronic 

15 reprographic systems", are advantageous in that they can be coupled with 
other components, by way of a network, to facilitate image processing 
operations among the components. An example of a network printing 
arrangement including a wide range of image processing capability can be 
found in U.S. Patent No. 5,113,494 to Menendez et al. (Issued: May 12, 

20 1992). 

As borne out by U.S. Patent No. 5,1 13,494, a significant amount 
of control for a network printing system resides in one or more network 
servers. The following patents disclose examples of systems including 
servers: U.S. Patent No. 5,220,674 to Morgan et al. (Issued: June 15, 1993) 
25 and U.S. Patent No. 5,243,518 to Holt et al. (Issued: September 7, 1993). 
Brief discussions of U.S. Patent Nos. 5,1 13,494; 5,220,674; and 5,243,518 are 
provided in U.S. Patent No. 5,872,569 to Salgado et al. (Issued: February 16, 
1999). U.S. Patent No. 5,243, 518 is particularly noteworthy to the area of 
electronic printing in that it discloses a layered document services architecture 
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facilitating operation and interconnection of electronic printing systems with 

both resident and non-resident work inputs. 

Programming a job is often achieved with a "job ticket". For 

many printing systems, the job ticket is provided in the form of one or more 
5 programmable dialogs, each programmable dialog including values which are 

selected with a user interface, such as the user interface found in a DocuTech 

("DocuTech" is a registered trademark of Xerox Corporation) printing system. 

Job tickets can vary dramatically in both structure and functionality. In one 

instance, the job ticket may assume the form of a relatively simple dialog 
10 displayed on a liquid crystal display ("LCD"). Attributes of a corresponding job, 

such as desired image processing, designated stock and finishing 

characteristics may be displayed for setting of suitable output values, e.g., 

stock size. 

Disclosures of relatively complex job ticketing approaches are 
15 provided by way of the following patents: 

U.S. Patent No. 5,079,723 to Herceg et al. (Issued: January 7, 

1992) 

U.S. Patent No. 5,260,805 to Barrett (Issued: November 9, 

1993) 

20 U.S. Patent No. 5,398,289 to Rourke et al. (Issued: March 14, 

1995) 

U.S. Patent No. 5,450,571 to Rosekrans et al 

(Issued: September 12, 1995) 
U.S. Patent No. 5,600,762 to Salgado et al. (Issued: February 4, 

25 1997) 

The patents listed above are discussed in U.S. Patent No. 
5,872,569 to Salgado et al. Other patents providing further background in the 
area of user interface design include: 
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U.S. Patent No. 5,513,126 to Harkins et al. (Issued: April 30, 

1996) 

U.S. Patent No. 5,718,520 to Mackay (Issued: February 17, 

1998) 

5 U.S. Patent No. 5,872,569 to Salgado et al. is directed toward a 

system, with a screen display, and an application server, is provided. 
Preferably, the application server registers one of a plurality of metaphor 
elements with a set of device attributes. A status indicating metaphor or a 
control metaphor is developed for use with the one of the plurality of metaphor 

10 elements. When displaying a metaphorical template, including the one of the 
plurality of metaphors on the screen display, the status indicating or control 
metaphor is associated with the one of the plurality of metaphor elements for 
facilitating the programming of a job or controlling an output of the job. 

U.S. Patent No. 5,513,126 Harkins et al. is directed toward a 

15 method for a sender to automatically distribute information to a receiver on a 
network using devices (such as printers and facsimile machines) and 
communication channels (such as electronic mail) defined in a receiver profile. 
The receiver profile establishes the properties and mode for receipt of 
information for receivers on the network and the profile is published in a 

20 network repository for all network users or is accessible by selected groups or 
individuals on the network. Receivers have additional control over network 
senders by defining an information filter which further controls sender channel 
access (to a receiver) by defining some channels as having priority of access 
such as direct or delayed access, as well as selectively permitting senders to 

25 override the receiver profile. Consequently, receiver profiles provide a 
variable receiver definable link to senders using multiple forms of media as 
well as multiple hardware platforms and network configurations. 

U.S. Patent No. 5,718,520 to Mackay is directed toward an 
apparatus for automatically modifying a print job ticket having a plurality of 
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page tickets is provided. Each page ticket is programmed with one or more 
print job attributes and each print job attribute is associated with one or more 
print job characteristics. In practice, one or more values are assigned 
respectively to the one or print job characteristics. The print job attributes and 
5 print job characteristics are stored in memory as a set, and a portion of the set 
is scanned with a processor to determine each page ticket upon which a print 
job characteristic first value is located. A set of page tickets is selected from 
the page ticket(s) determined with the processor and, for at least a portion of 
the set of page tickets, one or more print job characteristic first values are 
10 changed to print job characteristic second values so that the need on the part 
O of a printing system user to manually change print job characteristic first 

values to print job characteristic second values is minimized. 

ill As is known, job tickets can also be provided in hardcopy form. 

ffl 

rg A discussion of "paper III" is provided in U.S. Patent No. 5,243,381 to Hube et 

15 al. (Issued: September 7, 1993). In accordance with U.S. Patent No. 
O 5,243,381, a link to a job ticket is provided through a "separator sheet" upon 

m which one or more bar codes are printed. In practice, when an image capture 

p device, such as a scanner, reads the bar code, a corresponding pre-stored set 

of job programming instructions is retrieved from memory for use in processing 
20 a job. 

In the context of print job production, it is understood that the 
following problem or publishing need can arise: 

Users often need to print a single piece of information (a 
document) more than one way, essentially producing multiple different 
25 physical forms of a document. For example a lecturer, about to give a 
presentation, may desire to print his or her presentation in the following ways 
(or job types): 

□ 50 stapled, duplex sets w/covers to use as handouts 

□ 1 simplex set of overhead transparencies for the actual 

30 presentation 
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□ 1 simplex set of punched paper (for the presenter to keep 

notes on) 

It is understood that, in a significant number of currently available 
digital printers/copiers, this presentation would be processed by submitting a 

5 single file, expressed in a conventional page description language ("PDL") 
multiple times to a printer, where a different "job ticket" is provided for each 
way the presentation is to be printed or rendered. To the printer, these jobs 
appear to be distinct jobs and are processed totally independent of each other. 
Obviously, submitting PDL across a network to the Print Server multiple times 

10 is inefficient. 

A few products, such as DocuTech with its DocuSP controller 
("DocuTech and "DocuSP" are trademarks of Xerox Corporation), solve the 
problem of multiple PDL submissions by allowing a user to SAVE a job, with 
its associated first job ticket, on a print server. The job data is then referenced 
15 by a pointer in subsequent job submissions containing just new job tickets. 
That is, each new job ticket is referenced (one-at-a-time) to a print ready file. 
Job Tickets can also be saved and later retrieved for application to a particular 
job. 

While saving jobs and tickets, in the manner described above, 
20 goes a long way toward addressing the perceived problem (i.e. the problem of 
printing a presentation of multiple job types in multiple submissions), one 
further problem remains: How can all job tickets applicable to a job be 
logically related to the job, and the resulting relationship be maintained over 
time? 

25 By way of the above-mentioned U.S. Patent No. 5,600,762 to 

Salgado et al., it is known that a print job, may be a "composite job" where, the 
composite job is really nothing more than the packaging of multiple individual 
job segments into a singular entity that is printed together in some determined 
quantity. In this case, each job segment consists of its own page images 

30 (usually in PDL form) and an associated "segment" ticket. These segments 
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are concatenated together and processed by the printer to produce a 
collection of documents that are somehow related. 

The approach of U.S. Patent No. 5,600,762 to Salgado et al. 
may be used to print what are known as "course packs". An example of a 

5 course pack might include a job where the first segment of the job is an 
instruction sheet on green paper to be read by the student, the second 
segment is a set of readings the student is directed to read, and the third 
segment is a test to be taken after the student has read the material. Usually, 
for these composite jobs, some job ticket parameters, such as print quantity, 

10 are best applied globally and must be placed in a global ticket, whereas other 
job ticket parameters, such as media, are best applied within the individual 
segment tickets. 

This approach, however, is believed to fall short of addressing 
the publishing need identified above. To produce the multiple forms of the 

is presentation in the example posed immediately above, the page images 
would, at least in some instances, have to be repeated in each of the 
segments - that could be wasteful - and the global programming could cause 
some problems (e.g. produce the same quantity of overheads as handouts). 

"Interpress", a Xerox developed PDL, addressed the above- 

20 identified publishing need through use of a programming instruction known as 
"IFCOPY". IFCOPY is intended to allow certain copies within a multi-copy job 
to be rendered with alternate programming (e.g. copies 1-3 on white paper 
and copy 4 on blue paper). However, there appear to be several problems 
with using this approach in the context of print job programming: 

25 First, the IFCOPY instruction is coded deep within an Interpress 

master (possibly at multiple page locations) and cannot be easily changed 
once the PDL file (with its corresponding programming) is created. To use the 
IFCOPY functionality in a manner similar to a job ticket, a user would be 
required to parse the PDL file, locate relevant programming or instruction(s), 



-7- 



replace it with an alternate instruction(s), and rebuild the master. This is 
hardly the type of programming that would be suitable for use in a typical 
printing arrangement. 

Second, its effective use would also require that the PDL 

5 language itself be capable of specifying all the printing instructions necessary 
to produce a job. However, because many complex job ticket instructions are 
often device dependent and not associated directly with image rendering, they 
are often not considered appropriate instructions for inclusion in the PDL, and 
thus do not exist in the PDL. 

10 In view of the above, it would be desirable to provide a system 

(with suitable attendant process) in which multiple job tickets can be 
programmed for a single submission to a printer, along with one corresponding 
set of image data, to yield multiple job renderings. Moreover, it would be 
desirable to provide a convenient vehicle for storing the tickets together with 

15 the image data so that the programming for the multiple job renderings can be 
readily manipulated or edited. 

All of the disclosures for the patents referenced in the above 
Background are incorporated herein by reference. 

SUMMARY OF EMBODIMENTS OF THE INVENTION 

20 In one embodiment of the disclosed invention, there is provided 

a method for use in a document processing system with at least one document 
processing subsystem where a job, including a set of images, is processed 
multiple times, in response to input provided by a user, to obtain first and 
second job processing events of the job. The method includes: 

25 • programming a first job control ticket with a first set of 

attributes, the first job control ticket controlling a manner in which the job is to 
be processed in the first job processing event; 
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• programming a second job control ticket with a second set 
of attributes, the second job control ticket controlling a manner in which the job 
is to be processed in the second job processing event; 

• linking the first and second job control tickets with the set 
5 of images so that, upon one submission of the job to the document processing 

subsystem, the job is processed in the first job processing event with the first 
job control ticket and in the second job processing event with the second job 
control ticket, wherein the job need not be submitted to the document 
processing subsystem multiple times. 
u 10 In another embodiment of the disclosed invention, there is 

y provided a method for use in a document processing system including a 

O memory and at least one document processing subsystem where a job, 

jjj including a set of images, is processed in accordance with a selected job 

fj control ticket including a set of programmed attributes. The method includes: 

s 15 • storing one or more job control tickets in the memory, the 

,h one or more job control tickets including the selected job control ticket; 

JJj • creating a master job control ticket including one or more 

O user selectable portions, the one or more user selectable portions being 

corresponded respectively with the one or more job control tickets; and 
20 • selecting a first one of the one or more user selectable 

portions, the first one of the one or more user selectable portions being 
corresponded with the selected job control ticket so that, upon submitting the 
job with the master job control ticket to the document processing subsystem, 
the job is processed in accordance with the set of programmed attributes of 
25 the selected job ticket. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 is schematic, graphical representation of a job in which 
a master or "super" job ticket is linked with a plurality of job tickets, which 
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plurality of job tickets are, in turn, linked with a corresponding set of image 
data; 

Figure 2 is a flow diagram depicting a process for developing the 
job graphically represented in Figure 1 ; 
5 Figure 3 is a flow diagram depicting a process for editing the 

master ticket of Figure 1 and/or the job ticket(s) linked therewith; 

Figure 4 is a flow diagram depicting, in part, a manner in which 
the job graphically represented in Figure 1 is managed in a network context; 

Figure 5 is an isometric view depicting an electronic reprographic 

10 system; 

Figure 6 is a block diagram depicting the input, output and 
control architectural elements of the reprographic system shown in Figure 1 ; 

Figure 7 is a view depicting an exemplary job programming ticket 
and job scorecard displayed on a User Interface (Ul) of the printing system 
15 shown in Figure 1; and 

Figure 8 is a block diagram depicting a network printing system 
including the printing system of Figure 2. 

DETAILED DESCRIPTION OF EMBODIMENTS THE INVENTION 

While the present invention will hereinafter be described in 
20 connection with a preferred embodiment thereof, it will be understood that it is 
not intended to limit the invention to that embodiment. On the contrary, it is 
intended to cover all alternatives, modifications and equivalents as may be 
included within the spirit and scope of the invention as defined by the 
appended claims. 

25 Turning now to Figures. 5 and 6, there is shown an exemplary 

electronic reprographic system 2 for processing print jobs (with corresponding 
job programming) in accordance with the teachings hereof. Reprographic 
system 2, for purposes of explanation, is divided into a scanner section 6, 
controller section 7, and printer section 8. While the present embodiments are 
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described with reference to a specific reprographic system, i.e., the DocuTech 
Network Publishing System, the described embodiments may be used with 
other types of processing systems having at least some similar capabilities. 

Referring to the illustrated embodiment of Figure 6, scanner 

5 section 6 incorporates a conventional image capture platform of the type 
disclosed in U.S. Patent No. 5,442,732 to Matysek et al., the disclosure of 
which is incorporated herein by reference. The Scanner 6 may include linear 
arrays (not shown) for capturing analog image signals or pixels representative 
of an image scanned which, after suitable processing by processor 25, are 

10 output to controller section 7. Processor 25 converts the analog image signals 
output by array 24 to digital image signals and processes the image signals as 
required to enable reprographic system 2 to store and handle the image 
signals or data in the form required to carry out the job programmed. 
Processor 25 also provides enhancements and changes to the image signals, 

15 such as filtering, thresholding, screening, cropping, and reduction/enlarging. 

In the exemplary reprographic system 2 (Figure 6), printer 
section 8 comprises a laser type printer and, for purposes of explanation, is 
separated into a Raster Output Scanner (ROS) section 87, print module 
section 95, paper supply section 107, and high speed finisher 120. It should 

20 be appreciated that the high speed finisher 120 could comprise one or more 
inline or offline finishers. Finally, in the exemplary reprographic system 2, 
controller section 7 is, for explanation purposes, divided into an image input 
controller 50, User Interface (Ul) 52, system controller 54, main memory 56, 
image manipulation section 58, and image output controller 60. 

25 As best seen in the illustrated embodiment of Figure. 5, Ul 52 

controls a combined operator controller/CRT display consisting of an 
interactive display screen (e.g. touchscreen) 62, keyboard 64, and mouse 66. 
Ul 52 interfaces the operator with reprographic system 2, enabling the 
operator to program print jobs and other instructions (as will be discussed in 
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further detail below) and to obtain system operating information, instructions, 
programming information, and diagnostic information. Items displayed on 
display screen 62, such as files and icons, are actuated by either touching the 
displayed item on display screen 62 with a finger or by using mouse 66 to 

5 point a cursor to the item selected and keying the mouse 66. 

When the image data of main memory 56 requires further 
processing or is required for display on touchscreen 62 of U I 52, or is required 
by printer section 8, the data is accessed in main memory 56. Where further 
processing other than that provided by processor 25 is required, the data is 

10 transferred to image manipulation section 58 where the additional processing 
steps such as collation, make ready, and cropping are carried out. Following 
processing, the data may be returned to main memory 56, sent to Ul 52 for 
display on touchscreen 62, or sent to image output controller 60. 

Referring to the illustrated embodiment of Figure. 7, jobs are 

15 programmed in a Job Program mode in which there is displayed on 
touchscreen 62 a Job Ticket 150 and a Job Scorecard 152 for the job being 
programmed. Job Ticket 150 displays various job selections programmed 
while Job Scorecard 152 displays the basic instructions to the system for 
printing the job. An extensive discussion of a job ticketing arrangement 

20 suitable for use on a reprographic system (of the type contemplated hereby) is 
provided in U.S. Patent No. 5,079,723 to Herceg et al. 

As will be appreciated by those skilled in the art, job 
programming can be performed at a network client when the job is to be 
programmed for application in a network context. Job programming 

25 techniques useful for employment in the network context are discussed in U.S. 
Patent No. 5,493,634 to Bonk et al. (the disclosure of which is incorporated 
herein by reference) and U.S. Patent No. 5,450,571 to Rosekrans et al. 

Additional details of construction and operation of the exemplary 
reprographic system 2 discussed above will not be detailed herein, since such 
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are well known in the reprographic art. Moreover, for ease of presentation, the 
processor 25, main memory 56 and Ul 52 interconnections and software 
controls therebetween will not be discussed in any great detail, since such is 
known in the art. What will be discussed, however, is a process for linking a 

5 set of job tickets with a master or "super* ticket to greatly facilitate the job 
programming process mentioned above. 

Referring to Figure 8, the controller 7 is, in one of several 
contemplated connective arrangements, coupled with a network arrangement 
170 by way of a network interface 172. The network interface 172 includes all 

10 of the hardware and software necessary to relate the hardware/software 
components of the controller 7 (or, alternatively, the image input 6) with the 
hardware/software components of the network arrangement 170. For 
instance, to interface various protocols between the server and the network 
arrangement, the network interface could be provided with, among other 

15 software, one of Novell's "Netware" packages ("Netware" is a registered 
trademark of Novell Corp). 

In the illustrated network arrangement 170, various I/O and 
storage devices are interconnected with a bus 174. In particular, the devices 
include, among others, the following: I/O Apparatuses 176, Print Services 

20 178, Scan Services 180 and Tape Storage (or other suitable mass memory 
related) Devices 182. In the present example a given I/O Apparatus includes a 
client workstation, such as any suitable PC compatible apparatus. 

It will be appreciated that, in practice, many network systems 
would be appropriate for use with the presently disclosed embodiments. 

25 Accordingly, the functionality of the disclosed embodiments below might, in 
some instances, be enhanced through the deployment of networks such as 
those disclosed U.S. Patent No. 5,513,126 to Harkins et al. and U.S. Patent 
No. 5,872,569 to Salgado et al. Moreover, the illustrated embodiment of 
Figure 8 is particularly useful in a "scan-to-file" implementation of the type 
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disclosed in U.S. Patent No. 5,619,649 to Kovnat et al., the disclosure of which 
is incorporated herein. 

A "high level" discussion of some important aspects of the 
disclosed embodiment(s) follows below: 

The presently disclosed embodiment(s) permit multiple individual 
job tickets to be created for a single PDL document and activate some or all of 
those tickets from a "super" ticket to permit production of various physical 
forms of the document in one submission session. In one preferred 
embodiment, the system automatically creates a reference (pointer) for each 
individual ticket and adds the individual ticket to the super ticket. Thus the 
super ticket overlays individual job tickets and invokes the individual tickets by 
reference. Referring to Figure 1 , the relationship between the individual job 
tickets and the super ticket is shown in schematic, graphical form. 

In practice, it would not be necessary for all individual tickets to 
be activated by the super ticket. It should also be recognized that the super 
ticket might specify certain printing parameters (shown, for exemplary 
purposes, as a "[global] instruction" in the super ticket of Figure 1) that are 
best controlled at the highest level, thus buffering the print submission user 
from having to understand how to edit the more complex individual tickets. 

Implementation of the concept illustrated in Figure 1 is not 
technologically challenging, but would impact software design in some of the 
following ways: 

1) Job submission clients would preferably be provided with 
logic and Ul changes to support the programming and linking of multiple 
tickets for one job, 

2) A few additional Job Ticket Instructions would be created 
for enabling the system to encode various tickets and carry corresponding 
super tickets referencing information. However, in all other respects, the job 
ticket instruction encoding approach for the disclosed embodiment(s) would 
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employ currently accepted job ticket instruction encoding practices. For 
example, the job tickets could be encoded in ASCII or binary format. 
Moreover, the super ticket (along with its referenced individual tickets) could 
be embedded within given PDL file (as is currently achieved with Adobe 

5 Document Structuring Convention) or provided in a separate file with a pointer 
(or pointers) to the PDL file. 

3) Print server's job ticket parsing logic would be provided 
with the capability to recognize and handle multiple tickets (through use of the 
corresponding super ticket), and to subsequently generate the necessary 

10 quantity of prints for each "activated" individual ticket. Internally, these could 
be viewed as separate jobs to the system, but to the user, they would appear 
as one overall job. 

As will appear, the multiple print ticket scheme generally 
described above concept can be useful in "distribute and print" applications. 

15 For example, when a document is to be published at multiple remote sites 
which utilize printers from different product families, the individual print tickets 
could be programmed in accordance with the device dependent instructions 
required for each site's printer. In this example, the super ticket would control 
which printers are to receive the job and how many copies are to be produced 

20 at a given site. Under those circumstances in which printing is not required at 
one or more of sites, the super ticket could be set to "inactive" for individual 
tickets corresponding with such one or more sites. 

Referring now to Figures 2-4, a more detailed discussion relating 
to software design of the disclosed embodiment (s) is provided. 

25 Referring first to Figure 2, a routine for implementing super or 

"master" ticket development is described. When a user desires to construct a 
job with a super ticket, an exemplary master ticket development program is 
initiated at step 200. A suitable template, for use in creating the master ticket, 
is provided at step 202, and the user programs a current ticket set at step 204. 
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The term "set" is used with respect to job ticket programming step because, as 
is known, it may require multiple tickets to adequately describe the 
programming for a given job. Thus multiple tickets may be associated with a 
given single job. 

5 At step 206 the ticket (or tickets) for one job instance are linked 

to the master ticket with a suitable reference or link. By way of the query at 
step 208, the user is provided an opportunity to activate the current ticket set. 
If activation is desired, the state of the current ticket set is designated as "true" 
(step 210) and a portion of the master ticket template, as seen in Figure 1, is 
10 marked (step 214) so that the master ticket includes a checked box 
q corresponding with the current ticket set. 

n If activation is not desired, at least for the time-being, then the 

W state of the current ticket set is designated as false (step 216) so that the box 

ill 

qq for the current ticket set is left unchecked. It will be appreciated that a user 

vJ 15 can always check an unchecked box later for activation. 

Through steps 218 and 220, the user is provided with a 
Si mechanism by which to program as many ticket sets as needed for use with 

2 the super or master ticket. More particularly, at step 218, the user is asked 

U whether more job tickets are to be programmed. Assuming another job ticket 

20 set is to be programmed, the illustrated routine of Figure 2 permits the user, 
via step 220, to begin programming the next ticket set at step 206. 

As soon as all of the necessary job ticket sets have been 
provided, the routine proceeds to step 222 where the master ticket (with all of 
the corresponding programmed job ticket sets) is linked with a set of image 
25 data. In one example, the master ticket (with individual tickets) is embedded 
in a PDL file. 

Referring now to Figure 3, a method for editing the master ticket 
(Figure 1) and individual job tickets corresponding therewith, is discussed. 
When editing is desired, suitable editing software is accessed at step 224. In 
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the illustrative editing embodiment of Figure 3 (which only contemplates a few 
of numerous editing functions that can be performed with respect to the 
master ticket (and its attendant individual job tickets)), a user is provided with 
the opportunity to add/delete a job ticket or edit the attributes of an existing 

5 ticket in storage. Pursuant to adding a job ticket (step 226), a link between the 
ticket currently being added ("Current Job Ticket") and its corresponding 
master ticket is provided at step 228. 

At step 230, a user may activate the current job ticket. If 
activation is desired, the state of the current ticket is designated as "true" (step 

10 232) and a portion of the master ticket template, (Figures 1 and 2) is marked 
(step 234) so that the master ticket includes a checked box corresponding with 
the current ticket. 

If activation is not desired, at least for the time-being, then the 
state of the current ticket set is designated as false (step 236) so that the box 

15 for the current ticket set is left unchecked. As indicated above, a user can 
always check an unchecked box later for activation. 

At step 240, a user is provided with the opportunity to add 
another ticket. Assuming that another ticket is to be added, the system 
acknowledges that the ticket being added is a "next" or new ticket. Processing 

20 of the next ticket is then begun at step 228. 

Referring to step 244, the user is provided with an opportunity for 
deleting one or more job tickets. Assuming deletion is desired for one of more 
tickets, the link(s) is deleted, via step 246, and an appropriate clearing action 
is performed, at step 248, by clearing the selectable portion on the master 

25 ticket corresponding with the deleted ticket. It should be appreciated that it 
may be undesirable to purge any given ticket from the system since a user 
may seek to revive the "deleted" ticket at a later time. Thus, in one preferred 
embodiment, a given ticket is not actually deleted, but rather severed from the 
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master ticket and left in memory. In this way, a link between the severed ticket 
and the master ticket (or another master ticket) can be provided at a later time. 

At step 252, a user is provided with the opportunity to edit the job 
attribute(s) of one or more job tickets. Any requisite changes to one or more 

5 job tickets are then made by way of step 254. Two aspects of job ticket 
attribute editing are noteworthy. First, the editing of a ticket in no way changes 
the appearance of the master ticket. In this way editing is performed in a 
modular fashion and any recompiling of tickets to specifically accommodate for 
the editing is unnecessary. Second, attribute editing can serve as a very 

10 powerful tool in "make ready" applications. For instance, a user can create 
"variations on a theme" for any given job. This can be very useful in producing 
multiple characterizations of the same job or editing a job for output at one or 
more different sites in one or more network systems. 

Referring finally to Figure 4, an approach for network handling of 

15 one or more master tickets with their related components is described. The 
network handling or processing application is initiated at step 256. It is 
common practice in the network-printing environment to develop a job (with 
appropriate programming) at a client workstation (Figure 8). Pursuant to 
readying the job for transmission from the client to one or more target 

20 systems, it is conventional practice to compile the job (and programmed 
instructions) with a print driver. As contemplated in at least one embodiment, 
an image data set along with a master ticket (with linked/reference job tickets) 
is "packaged" by the driver (at step 258) for suitable transmission across the 
network. 

25 For ease of discussion, the package (which typically will include 

a PDL file with image data and embedded tickets) is viewed, in the illustrated 
technique of Figure 4, as being transmitted from one client to one target 
system. In practice, however, the package may be distributed across the 
network for processing at multiple sites. 
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It will be appreciated that submission of the package to a target 
system (or subsystem) need not be user driven. That is, the package can be 
submitted automatically, i.e., independent of the user, particularly in a network 
environment. For instance, a user will not necessarily be involved when the 
5 package is submitted to a target system (or subsystem) by a network server. 

In one example, the package is then transmitted to a remote 
system or object device (step 260) for suitable storage or spooling of the (1) 
Master Ticket, (2) Job Ticket(s), and (3) Related Image Data. Pursuant to 
such storage, a data structure similar to that shown in Figure 1 is implemented 
10 through steps 264 and 266. Pursuant to decomposing the job (step 268) all 
O active tickets (along with the master ticket) are read. Thus during an output 

» stage, multiple job renderings can be obtained, via step 270, by simply 

If; referencing each active job ticket designated on the master ticket. 

m In view of the description above, various features of the 

^ y 15 disclosed embodiment(s) can be readily recognized: 

M- One feature facilitates multiple job renderings to be obtained 

?jj through one submission. In one embodiment multiple job tickets are 

2 associated with a single image data set so that a single submission of a job to 

p a document processing subsystem permits the single image data set to be 

20 processed several times in accordance with the multiple job control tickets. 

In another embodiment the multiple job renderings can be 
greatly facilitated through employment of a "super" or master job ticket. That 
is, the user is provided the master ticket, with the master ticket having one or 
more user selectable portions - the one or more user selectable portions 
25 correspond respectively with one or more job control tickets. The user then 
selects at least one of the one or more user selectable portions and submits 
the single image data set with the master ticket to the document processing 
subsystem. In turn the single image data set is rendered in accordance with 
each job control ticket selected in the one or more user selectable portions. 
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In yet another embodiment, the master ticket is provided with a 
global instruction permitting a single operation to be performed across multiple 
job tickets associated with the master ticket. 

Another feature facilitates easy and effective editing over a 

5 package of one or more job control tickets. Editing functionality may include, 
among other operations, adding a job control ticket, deleting a job control 
ticket, or changing at least one attribute associated with a job control ticket. 
The manner in which a job ticket can be altered without impacting the master 
ticket promotes modularity. Moreover, modularity is further enhanced in that 

10 attributes can be added or deleted without impacting the master control ticket. 
The need to recompile a package including the master control ticket and 
associated job control tickets is minimized. 

Another feature facilitates distributed printing and make-ready 
operations. For example, when a document is to be published at multiple 

15 remote sites employing printers from different product families, the job control 
tickets of the master ticket can be programmed in accordance with the device 
dependent instructions required for the output device(s) of each site. Similarly, 
the job control tickets of the master ticket can be varied, in a make-ready 
context, to accommodate for the varying demands of an individual user at one 

20 or more devices. 

Yet another feature facilitates off-line finishing situations. For 
example, a user can prepare a job for finishing at two off-line finishing devices 
by varying two of the job control tickets of the master ticket. In turn, the 
finishing instructions can be printed, in machine-readable terms, for future use 

25 at the off-line finishing devices. 

Another feature facilitates readily adaptable job programming in 
a network setting. More particularly, a job structure including the master 
control ticket (with corresponding job control tickets) and associated image 
data can be easily developed at a print server for storage and future use. 
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Yet another feature permits an input device to be used in 
conjunction with a program to link first and second job control tickets with 
either a set of image data or a master job control ticket. In this way a single 
submission of a corresponding job to a document processing subsystem 

5 causes the job to be processed in the first job processing event with the first 
job control ticket and in the second job processing event with the second job 
control ticket. Accordingly, the job need not be submitted to the document 
processing subsystem multiple times. 

Another feature facilitates the storage of an advantageous data 

10 structure for use in a multiple job rendering scheme. In one example, a data 
structure in which first and second job control tickets are both linked to a set of 
image data is stored in memory. In another example, a data structure in which 
the first and second job control tickets are both linked to a master job control 
ticket is stored in memory. In each example, the data structure is applied in 

15 such a manner that a single submission of a corresponding job to a document 
processing subsystem causes the job to be processed in the first job 
processing event with the first job control ticket and in the second job 
processing event with the second job control ticket. Accordingly, the job need 
not be submitted to the document processing subsystem multiple times. 

20 It should be appreciated that the above-mentioned data structure 

is particularly useful in a network document-processing context. In one 
example, the data structure can be embedded in an electronic file or document 
for easy transmission across one or more networks. In another example, the 
data structure can be stored at a network server for ready access by multiple 

25 network users. 
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